The IP Multimedia Subsystem (IMS) is an architecture based on the Session Initiation Protocol (SIP) which creates a common platform for enabling a broad range of advanced Internet-based multimedia services and applications on top of a packet switched network.
In FIG. 1 illustrates a conventional procedure in an IMS network for registering a user equipment to the IMS, and for requesting for an IMS-based service. In the figure, only the basic nodes are presented, while any intermediate nodes, which are not affected by the present invention, are, omitted.
Among other functions, a Serving-Call Session Control Function (S-CSCF) node is a SIP server or a session control unit, which handles registration requests received from user equipments registered to the IMS. An S-CSCF node, which has received a request for an IMS-based service from a registered user equipment is responsible for the forwarding of the service request to a specific application server (AS) for further processing of the requested service.
The Home Subscriber Server (HSS) is the main data storage for all subscriber- and service related data of the IMS. The main data stored in the HSS includes a user profile for each user, registered to the IMS. A user profile is a collection of user-specific information that is permanently stored in the HSS. The user profile associated with a user is downloaded to the S-CSCF node upon receiving a request for registering the user to the IMS. The service profile comprises all public user identities, i.e. all identities which may be used when requesting services from the IMS. Public User Identities can be SIP URIs, e.g., bob.home@x.com, or tel URIs, e.g., tel:+46 8 123 456 67. The service profile also comprises trigger rules, which defines under which conditions a service request is to be routed to a specific application server. By checking the trigger rules associated with the user-identity inserted in the service request, the application server to which the service request is to be routed to from the S-CSCF node can be determined.
At the application server, the service request has to be linked to the user data previously stored in the application server and associated with the user identity retrieved from the service request. How this linking is achieved is out of scope of this invention. A well known method for efficiently linking a service request to the appropriate user data is, however, to use a hash function, wherein the user-identity, received in the service request may be used as the hash key.
If required, a user may define a plurality of different user-identities to be linked to the same user profile and the same data, stored in one or more application servers, i.e. identical service requests, having different user-identities, may trigger the same activity. Such alternative user identities are called aliases. An alias may also be used for providing limited access to data associated with another public user-identity.
In a first step 1:1 in FIG. 1, a provisioning system 100 creates all data required for executing services associated with a specific user identity in the HSS 101, including known user-identities, which may include one or more alias-identities. In another step 1:2, the provisioning system also creates the corresponding data, comprising user-identities, required in the associated application server 102. This data also comprises a first user-identity, and, depending on the application server functionality, also known alias-identities.
In another step 1:3, a user wanting to get access to the multimedia services provided by an IMS network register a user equipment 103 by way of sending a SIP register message to the IMS network. The SIP register message is sent to, and evaluated by the S-CSCF node 104, which has been allocated to the user. The S-CSCF node is essentially a SIP server, but it also acts as a registrar, which means that it maintains a binding between the location of a registered user equipment and the user identity associated with the user of the user equipment. When the S-CSCF node receives the register request, an updated user profile related to the user is downloaded to the S-CSCF node from a Home Subscriber Server (HSS) in step 1:4. The user-profile associated with a user comprises a private user identity, which is used for authentication purposes only, and one or more service profiles, each of which is applicable to one or more public user-identities.
After the user equipment has been registered, a request 105 for the desired service is sent to the S-CSCF node in step 1:5. In this case, the user is using alias-identity 1 when requesting for a service. By interrogating the user-identity in the service request in step 1:6, the S-CSCF node determines which trigger rules in the service profile associated with the respective user-identity that are fulfilled, and, thus, which application server to route the service request to for further processing of the requested service.
In another step 1:7, the service request 105, comprising the alias-identity 1 is routed to the application server, pointed to by the respective trigger rules.
In a final step 1:8, an appropriate data model is used for linking the user-identity, retrieved from the service request to the data associated with the respective user-identity. Such a linking procedure may be both complicated and resource consuming.
FIG. 2 illustrates an example of different user-identities, including alias-identities, associated with a user. The first user-identity, i.e. bob.home@x.com is defined as a first user-identity, which for example may give full access to the user data associated with the respective user, while the additional user-identities i.e. bob.work@x.com and bob.soccer@x.com may also give full or limited access to the respective user data, according to the trigger rules set up for the respective user-identity or alias-identity.
One problem with existing solutions is that the provisioning of an application server becomes complicated if the application server must be able to understand an alias-identity in a service request.
Another problem is that the data model of the application server, as well as the routing of requests becomes complicated if the application servers must be able to interpret and understand an incoming alias.
Yet another problem is that there are cases when it is required that all nodes in the IMS network share similar data models. This causes increased complexity when upgrading of the IMS network is necessary.
A requirement for extra database requests and more logic to be executed in the application server, are other problems which are connected with the handling of alias-identities.